QRZ! Ham Radio 6

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 6 / QRZ Ham Radio Callsign Database - Volume 6.iso / pc / files / t_gracil / p10r30e.txt < prev next >

Wrap

Text File | 1994-11-27 | 30KB | 658 lines

NOS302 Release 3.0e for the PackeTen November 23, 1992 The latest version of this software is always available for download from the Gracilis BBS. (708)-844-0183 ******************************************************************** This ZIP archive contains Binary image files for NOS302 for the Gracilis PackeTen Network Switch. If you purchased your PackeTen system prior to November of 1990 you probably have a Release 1 CPU, and should use the cpu_rel1.l and cpu_rel1.u files. Otherwise, use the cpu_rel2.l and cpu_rel2.u image files. Functionally, the software is identical for both systems, with the exception of the size of available EEProm memory storage. A release 1 CPU provides 2k of EEProm, while a release 2 has 8k. ******************************************************************** ******************************************************************** NOTE: Releases subsequent to 3.0d1 change the layout of the EEPROM... Therefore, It will be necessary to RE-enter all EEPROM parameters after installation of any release numbered 3.0d1 or higher, when upgrading from 3.0d or earlier releases. ******************************************************************** Checksums cpu_rel1.l : 0x7885 U2 on a PackeTen Release 1 CPU cpu_rel1.u : 0x7979 U3 on a PackeTen Release 1 CPU cpu_rel2.l : 0xD403 U2 on a PackeTen Release 2 CPU cpu_rel2.u : 0x0003 U3 on a PackeTen Release 2 CPU New Features/Enhancements: ************ NEW to 3.0e ************ ******************************************** New Features / Bug Fixes to PackeTen NOS302 ******************************************** 1. Remote sysop users may return to the Net/Rom simulator, from the command parser by using the "exit" command. 2. The (I)nfo feature of the remote user / Net/Rom Simulator interface has been enhanced to allow the user to exit the info dump by replying (N)o to a More? (Y/n) prompt. 3. The format of the remote configuration request command, (to be executed on the PackeTen) has been enahnced as follows: rmtcfg <hostid> <filename> [options] where: hostid The IP address or hostname of the host from which to request the file. filename The name of the configuration file to be sent. ( Note: for the Gracilis provided version of the rmtcfg SERVER code to be run on a PC, this filename should NOT include a drive or directory specification.) options Several new options have been implemented. -p <port> TCP port number to use for initiation of the server connection. If this option is not specified, then the default port: 1236 will be used. ( Note: If a value other than the default is used, the remote server must also be using the same value.) -t <timeout> Time to wait ( in seconds) for connection establishment to the remote configuration server. If the remote server fails to respond within this time period, the configuration attempt will be abandoned, and a secondary server, (if specified with the -h option) will be queried. If this option is not specified, a default timeout of 60 seconds is used. -h <hostid> Optional secondary host from which to request the configuration file, if the primary host fails to respond within the timeout period. -i This option indicates that the file being requested is to be used as the text for the "Info" message, that is available from the remote user / Net/Rom simulator interface. The option is intended to allow the switch to automatically request and update it's local info/help file, from a remote host. Examples: rmtcfg n4pcr.ampr.org switch.cfg To request file switch.cfg from host n4pcr.ampr.org using the default port, and 60 second timeout. rmtcfg n4pcr.ampr.org switch.cfg -p 3600 Specify that port 3600 should be used rather than the default port. rmtcfg n4pcr.ampr.org switch.inf -i Request file switch.inf and use it as the input to the local information message. rmtcfg n4pcr.ampr.org switch.cfg -h k9vxw.ampr.org -t 45 -p 3200 Request file switch.cfg first from n4pcr, with a timeout of 45 seconds, on port 3200. Then, if n4pcr fails to respond within the timeout period, attempt to obtain the file from k9vxw, using the same parameters. 4. Fixes to allow quoted strings to be entered into EEPROM cmd lines. Previous releases were unable to allow commands which contained quoted strings, since the (") sign is considered an argument break character, and is interpreted immediately upon entry, and not actually entered into the EEPROM. This release supports the use of the single quote (') as a pseudonym for the double quote ("), during entry into an EEPROM command line. This allows commands such as the beacon text command to contain a quoted string. For Example: ee co 1 beacon text 'N9QSO is on the Air!' will result in an eeprom line as follows: 1: beacon text "N9QSO is on the Air!" and will be properly interpreted at startup time. Another command for which this may be useful is the interface description command, as follows: ee co 1 iface port0 desc 'Local 1200 bps LAN channel 147.555' results in: 1: iface port0 desc "Local 1200 bps LAN channel 147.555" 5. New Improved HBOOT302.EXE The new hboot302.exe supports specification of non-standard base memory and i/o addresses, for use with the PC-PackeTen. For a usage message, use the following: hboot302 ? ============================================ 6. ERRATA from PackeTen Manual for IPC attach ============================================ NOTE: The attach commands to be used with the PC version of NOS, when communicating with an internal PC-PackeTen, AND with the PackeTen itself, have been enhanced since the last manual printing. The new attach procedures to be used with PC versions of NOS with PackeTen IPC drivers, are as follows: ======================================================== Attaching an Inter-Processor Communication (IPC) link - ======================================================== There are two IPC attach lines: one for the PackeTen card and one for NOS running on the PC. The PackeTen IPC attach line is as follows: attach ipc <processor (dc|mc|pc)> <name> <mode> [txqdepth] [rxbufs] [ip addr] The PC IPC attach line is as follows: attach ipc <vector> <processor (dc|mc)> <name> <mode> [base addr] [ctl addr] [txqdepth] [rxbufs] [ip addr] The differences between the two attach commands are that on the PC the the user must specify the interrupt vector number. Additional optional parameters for the PC version include the base I/O and Memory addresses to be used by the IPC driver. The interrupt vector number can only be used by the NOS IPC driver - It cannot be shared with other devices/cards in the PC. Where, "attach" is the command itself, "ipc" describes the basic link type, "vector" PC vector to be used by the IPC driver - only applies to NOS running on the PC and not to NOS running on the PackeTen card. "processor" the processor you want to communicate with. For NOS running on the PC this can be "mc" or "dc", main card (PTS-1) or daughter(PTS-1S), respectively. The daughter card can be attached to the main card and therefore allow the PackeTen switch to be used to support 10 communication links from the PC. For NOS running on a PackeTen card this can be mc|dc|pc, main card, daughter card, or the PC. For example to connect the main card to the PC specify pc. "name" is a user supplied interface name by which this link will be known, "mode" is the data encapsulation mode. Options are: ax25 or ipc. The ax25 encapsulation mode allows users to utilize AX.25 or NET/ROM connections across the IPC link in addition to IP datagrams. Mode ipc, is used to pass unencapsulated IP datagrams across the link, and will not allow AX.25 connections to be established through the IPC link. "base addr" is the address of the Tri-port ram on the PC version of the card. This address is set by a jumper on the card. The format of this field is - 0xD000:0000 Where all of the zero's are required to correctly specify the address. Possible values are: 0x8000:0000 0x9000:0000 0xA000:0000 0xC000:0000 0xD000:0000 (default) 0xE000:0000 "ctl addr" is the base I/O address to be used to communicate with the PackeTen from the PC. This optional command allows the system to be configured for a non-standard base address. If not specified otherwise, the IPC driver assumes a base address of 238 Hex. See the PackeTen documentation for I/O base switch settings. "txqdepth" is the maximum number of messages to be transmitted which the IPC driver will queue. The default value is 32. The purpose of this parameter is to ensure that the system does not run out of memory should the other processor fail to keep-up with the data traffic. To change this value after an attach use "kiss param 1", e.g. if the name used in the attach ipc command is ipc0 then "param ipc0 1 50" changes the txqdepth to 50. "rxbufs" number of pre-allocated receive buffers. The default value is 6. To maximize throughput IPC driver (like all PackeTen drivers) will not allocate memory during an interrupt and therefore must have memory buffers available whenever an IPC receive interrupt occurs. The user can tune his system system by specifying the number of pre-allocated receive buffers to be used by IPC. Note: The IPC Statistic RxNoBufs tells how many times the IPC driver did not have a pre-allocated receive buffer available when an IPC receive interrupt occurred. To change this value after an attach use "kiss param 0". For example, if the name used in the attach ipc command is ipc0 then "param ipc0 0 15" changes the number of pre-allocated receive buffers to 15. "ip addr" optional parameter to be used as the IP address associated with this particular link. ************ NEW to 3.0d7(a) ************ 1. This load provides fixes to AX.25 flow control (RNR) and timer handling. All versions of NOS - AX.25 to date 11/6/92 contain a bug in the state machine which fails to properly implement flow control, if the incoming queue on an AX.25 circuit fills, due to an outgoing cross-connection failure or congestion. This release fixes the flow control problem, properly implementing RNR flow control to the source of the incoming circuit. This is a special release for Brian Kantor, prior to release of a completed 3.0e load. All fixes for this release will be officially applied to release 3.0e. ************ NEW to 3.0d7 ************ 1. Fix for high speed baud rate calculation for Async 302 ports. We now properly support 38.4kb and 57.6kb and higher async rates. 2. Fix for lost TX Events on synchronous 302 ports. This bug could cause a 68302 port to be unable to transmit untill after a system restart. Typically, this was caused by the reception of a frame during boot up time. This release corrects the problem. ************ NEW to 3.0d6 ************ 1. Fix bug which caused the domain client to mark a timeout on a request, as an unknown entry... Thereafter it would not even try to resolve it. It would simply return host unknown. 2. Fix lingering tcp connections from abandoned finger requests. Similar to fix in 3.0d4 for mbox. 3. Added an outcall connection timeout for mailbox users. If a user connect request fails to complete in time, it is automatically aborted. The default timer value is 120 secs. Command format: mbx outcall <seconds> 4. Fixed yet another bug in the Uptime reporting It wouldn't properly report the # weeks... ************ NEW to 3.0d5 ************ 1. This release fixes a compiler/optimizer bug, which affected use of the 8530 ports in synchronous mode with internal clocking, and nrzi encoding. The symptom fixed was that sometimes ports 3 or 4 would not properly transmit after initialization. The transmitter would begin working properly only after reception of a frame. The bug was that the compiler optimizer saw that the data from some of the reads of the data registers of the 8530 port were not used, and it assumed that they were not necessary, and therefore removed them, without warning... YUKK!!! Those reads were a necessary part of the DPLL loopback initialization routine, and consequently, the DPLL never started up until incoming data was received. While it is not known exactly how long this problem has existed, I have tested versions all the way back to 2.1, with the problem still in evidence. Since this release appears to have fixed the problem cleanly, it is recommended that all switches which are directly utilizing 1200 bps modems (i.e. not TNCs), should update to this release. ************ NEW to 3.0d4 ************ 1. Force all outgoing AX.25 connection initiation attempts to flush any previously queued data for the destination node, before attempting to make the new connection. This is intended to fix a problem with data from a previous downlink being sent thru a new connection to the destination node, upon initial connection exchange. 2. Close and RESET any outcall/downlink connections associated with a user whose mailbox session is timed out. This eliminates TCP connections which had been being left laying around when a remote user timed out, leaving a cross link in place. ************ NEW to 3.0d3 ************ 1. This is a simple one feature release. A mailbox user may now disable the "escape" char while using the PackeTen to transport BINARY data through the system. This will allow BBS'es to connect to the PackeTen, disable the escape char, and forward BINARY traffic. The format is as follows: (E)scape disable <CR> - to turn it off. (E)scape <CR> - to display current settings. (E)scape enable <CR> - to re-enable it. (E)scape <char> <CR> - to change it. ************ NEW to 3.0d2 ************ 1. Configuration of a PackeTen from a remote configuration file. A new command "rmtcfg" has been added to allow the PackeTen to request a configuration file from a remote "rmtcfg server". This command works in conjunction with a "rmtcfg server" which receives the request and sends the contents of the specified file to the PackeTen. The PackeTen receives the data and interprets it as if it had been entered as operator commands. This feature is intended to allow the sysop to generate large configuration control files without the need to worry about the limit on the number of commands which may be entered into the PackeTen's local EEPROM. After initial configuration of a PackeTen node through EEPROM commands, (including routing information to the host on which the "rmtcfg server" will be running) it is expected that the "rmtcfg" request command would typically be used as the last command to be executed from the EEPROM. This will allow fully automated configuration in cooperation with a remote system. The format of the remote configuration request command, (to be executed on the PackeTen) is as follows: rmtcfg <hostid> <filename> [port #] where: hostid The IP address or hostname of the host from which to request the file. filename The name of the configuration file to be sent. ( Note: for the Gracilis provided version of the rmtcfg SERVER code to be run on a PC, this filename should NOT include a drive or directory specification.) port # Optional TCP port to use for initiation of the server connection. If not specified, then port 1236 will be used. ( Note: If a value other than the default is used, the remote server must also be using the same value.) Examples: rmtcfg n4pcr.ampr.org switch.cfg To request file switch.cfg from host n4pcr.ampr.org OR rmtcfg n4pcr.ampr.org switch.cfg 3600 To specify that TCP port 3600 should be used rather than the default port. In order for the PackeTen to be able to request a remote configuration file, a "rmtcfg server" must be available which understands the PackeTen's request, and answers appropriately. A version of such a server is provided for standard KA9Q NOS, running on a PC. NOTE: The source code for this server is contained in the Gracilis modified version of KA9Q NOS for the PC, which is also available on the BBS. Once NOS is running on the PC, a "rmtcfg server" must be started, BEFORE any interfaces are attached for use by the PC. This must be done so that as soon as the interfaces are activated, they will acknowledge remote configuration requests. If the server is NOT activated before such a request is received, the request will be denied, and the remote station will not receive it's configuration file. The format of the command necessary to start the Gracilis remote configuration server running on a PC version of NOS is as follows: From the NOS command line on the server PC: start rmtcfg [port #] where the optional port # is the TCP port on which to listen for requests from the PackeTen. If no port is specified, then the server will utilize port# 1236 as a default. 2. AX.25 Learned routing enhancements. This release provides ax.25 "learned" routing which is intended to be fully compatible with standard TNC's and netrom software. In the past, if a user connected to the switch using a digipeated path, the switch would return to him using the same path. Additionally, all future connections from the same user would have inherited the "learned" digipeated path, regardless of the fact that they might now be attempting to make a "direct" connection. This situation was also true of outgoing user initiated "downlinks" from the node to other ax.25 stations. Once a digipeated path existed to a given destination, it remained the path of choice until a sysop intervened and manually removed the "learned" route. This behaviour is peculiar to NOS and is not typical of TNC's or netrom systems. The bug exists in all previously known versions of KA9Q NOS and it's derivatives. This release corrects the behaviour as follows: If an ax.25 route is manually entered by an operator command, it is considered "permanent". It will not be overridden under any circumstance other than another specific operator command to delete it. Therefore, regardless of digipeaters used by the remote station, or the downlink route specified by a local node user, the "permanent" routing information will be used to make the specified connection. If no "permanent" return route exists to a destination, then the route used by an incoming packet is "learned" as a temporary route, and used in subsequent AX.25 routing. If future packets are received from the same source, with a different digipeater list, (or no digi's), then the previously "learned" route is removed and the new one added. This behaviour is also used for outgoing "downlinks". When a user specifies a digipeater path to be used to downlink to another ax.25 station, the digi path is "learned" and is used for subsequent connections until a different path is specified. 3. Fix for occasional garbage transmitted from an async 8530 port configured for KISS or SLIP use. This bug would occasionally cause an extremely long frame to be sent out an 8530 port (ports 3 or 4) when they were configured for KISS or SLIP modes. The frame would contain apparently random data from previously sent/received frames. 4. Fix for occasionally truncated receive frames on synchronous 68302 ports (ports 0,1,2) when configured with an internal 9600 bps G3RUH modem, under poor rf link conditions. If, during the reception of an incoming packet, the DCD signal from the modem dropped, even for an instant, the incoming frame is aborted and marked as possibly invalid. The sync302 driver code was not properly handling this condition, and would occasionally allow a truncated frame to be passed up to the network layers as it it were complete. While this behaviour would typically not affect TCP connections, since they use their own internal checksum mechanisms, NETROM and AX.25 connections would not detect the loss, and therefore some data would simply be lost. Note that this condition only appeared when the rf path was marginal to the point that DCD was flickering even during the presence of valid data. This bug has been fixed, and should no longer be an issue. ************ NEW to 3.0d1 ************ 1. The TCP backoff timer is now selectable between binary (exponential) and linear ( add a fixed constant for each backoff ). The linear setting should help with busy or poor links to maintain a reasonable retry rate, and not cause sessions to appear to hang, due to very long backoff times. 2. The RIP TTL value has been made into a configurable parameter. This should make the use of RIP on radio channels viable as an alternative for dynamic routing. The default setting is 1800 seconds, or 1/2 hour. 3. The AX25 BLIMIT parameter meaning has been changed to represent the MAXIMUM time between AX.25 level 2 retries. Effectively capping the backoff time on a connection, so as to prevent extremely long retry timers due to intermittent or poor links. The default is set to 60 secs. 4. The REMOTE USER interface has been changed to allow USERS to specify the interface/port name (for outgoing downlinks from the switch) without regard to CASE SENSITIVITY. This is intended to help with users who are not used to dealing with mixed case characters. 5. The maximum password length for the system has been extended to 25 characters. 6. A character selection bug has been fixed in the secure mode of sysop password operation. Previous versions would prompt for a sequence of letters, but only from the first 7 letters of the password. This has been fixed now to select from all letters of the master password. 7. The default condition for the AX.25 T3 timer has been changed from 0 (disabled) to 180 seconds. This was done to prevent a default configured switch from eventually running out of socket connections, because it was maintaining lots of old DEAD connections. By defaulting to 3 minutes, the switch will poll connections which have not been active, and eventually close those connections, if they do not answer. 8. The default has been changed for the AX.25 version. AX.25 Version 2.0 will now be the default. 9. A bug which caused the uptime report to ROLL OVER after 3 1/2 weeks has been fixed. The timer should now run for 500 weeks without a rollover. 10. A new command has been added to allow the sysop to enable/disable the "Linked to" messages. mbox linkmsg <on|off>. The default is off. 11. A change has been made to restrict outgoing connections from remote IP USERS who have logged into the switch with an id which is not a valid callsign. ( Simple letters/number/no punct etc check ). If such a user attempts to issue an outgoing connection, he is issued a "permission denied" message and directed to log in using his/her amateur callsign.